home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Libris Britannia 4
/
science library(b).zip
/
science library(b)
/
PROGRAMM
/
ASSEMBLE
/
2593.ZIP
/
ELINK.ZIP
/
MANUAL.TXT
< prev
next >
Wrap
Text File
|
1990-10-06
|
77KB
|
2,490 lines
Table of Contents
ELINK.....................................................3
What a linker does....................................3
How object files are constructed......................4
Standard Object Module Records....................4
BLKDEF........................................4
BLKEND........................................4
COMENT........................................5
DEBSYM........................................5
EXTDEF........................................5
FIXUPP........................................6
GRPDEF........................................8
LEDATA........................................9
LIDATA........................................9
LINNUM.......................................10
LNAMES.......................................10
MODEND.......................................11
PUBDEF.......................................12
SEGDEF.......................................12
THEADR.......................................13
TYPDEF.......................................13
Microsoft Enhancements to OMF....................14
COMDEF.......................................14
LCOMDEF......................................14
LEXTDEF......................................14
LPUBDEF......................................15
32-bit Enhancements to OMF.......................15
PharLap 32-bit Enhancements..................15
FIXUPP...................................15
LEDATA...................................15
LIDATA...................................16
LINNUM...................................16
MODEND...................................16
PUBDEF...................................16
SEGDEF...................................16
Microsoft 32-bit Enhancements................17
FIXUPP...................................17
LEDATA...................................17
LIDATA...................................17
LINNUM...................................17
MODEND...................................17
PUBDEF...................................17
SEGDEF...................................18
How ELINK works......................................18
Segment combining rules..............................18
Input....................................................20
Output...................................................21
Errors...............................................21
Warnings.............................................21
Map file.............................................21
Output (continued)
Parameter List...................................21
File List........................................22
Segment Map......................................22
Symbol Lists.....................................22
Verbose mode.........................................22
Output file..........................................23
Intel Hex........................................23
Intel Hex32......................................23
Motorola S-records...............................24
OMF..............................................24
Merging output files.................................24
Return values........................................25
The ELINK command line...................................26
How ELINK reads its command line.....................26
The ELINK command line: an example...................27
Switches.............................................28
-CASE............................................28
-COMBINE.........................................28
-COMMENT.........................................28
-DUPERR..........................................28
-DUPOK...........................................28
-ERR.............................................28
-FLAT............................................29
-HEX.............................................29
-HEX32...........................................29
-LINE............................................29
-MAP.............................................29
-NO32............................................29
-NOADDRESS.......................................29
-NOALPHA.........................................29
-NOFILES.........................................30
-NOLINE..........................................30
-NOPARMS.........................................30
-NOSEGMAP........................................30
-NOWARNING.......................................30
-OFFSET..........................................30
-OMF.............................................30
-RELAXED.........................................30
-SRECORD.........................................31
-VERBOSE.........................................31
-WARNING.........................................31
Appendix A: Error Messages...............................32
Appendix B: Warnings.....................................38
Index....................................................39
Page 2
ELINK
ELINK is an Embedded systems LINKer. Its purpose is to link object
files into a form suitable for embedded systems, particularly for
firmware.
What makes ELINK different from the other linkers in the marketplace
is that it creates binary images suitable for burning into ROM's
directly from object files, it can handle the Intel 80386's and
80486's 32-bit code, and it can link together 32-bit object files
created by both PharLap and Microsoft.
To understand this, it is necessary to understand what a linker does,
how object files are constructed, and how PharLap and Microsoft have
taken divergent paths to extend object files to handle 32-bit code.
What a linker does
In the beginning are the source files, the form (allegedly) readable
by humans. The source files are translated by compilers and
assemblers (collectively called language translators) into object
files. The object files, in the Intel world, contain information
about the data and executable code, derived from the source files.
This information includes the names of external references, the names
of public symbols, the names and attributes of the segments and
groups, and the code itself. In the case where references were made
to objects external to the source file, there is also information
pertaining to how those references are to be resolved. The linker
takes this information in, matches up the externals to the publics,
resolves the external references, generates the binary code, and
creates a new file containing the linked code and data.
In the DOS world, the linker's output is usually an executable
program. That program still contains references that aren't resolved,
as they pertain to absolute addresses that can't be determined until
DOS loads the program into memory. At that time, those addresses are
calculated. ELINK resolves those addresses as well, on the theory
that if the code and data are going to be burned into ROM's, you, the
programmer, already know exactly where the code is going to start.
Page 3
How object files are constructed
The object files created by Microsoft-compatible and PharLap-
compatible language translators are a subset of Intel's 8086
Relocatable Object Module Format, or OMF for short. Each object file
is made up of object records. Each object record follows a common
format: a single byte, which identifies the type of record, a two-byte
word, which is a count of the bytes in the record, the bytes making up
the record, and a single byte checksum. Also common to the object
records are these rules:
∙ Numbers are stored in standard Intel format: least significant
byte first, then next least, and so on.
∙ Indices are the exception to this rule. Indices between 0000 and
007F are stored as a single byte. Indices between 0080 and 7FFF
are stored most significant byte first, then least significant
byte. The first byte is stored with its most significant bit set
as a flag that the index is two bytes.
∙ Names are stored with a single byte holding the character count
followed by the symbols of the name. Thus "ELINK" would be
stored as 05 45 4C 49 4E 4B.
Here is a list of the record types ELINK recognizes and a short
description of each record:
BLKDEF
+--------------------------------------------------+
|7A|RLEN|BLK BASE|BLK INFO|PROC INFO|TYPE INDEX |CS|
+-----------------------------------+-----------+--+
|Conditional|
+-----------+
The Block Definition Record contains information about procedures
defined in the source file. ELINK skips over this record, but does
verify that the checksum is correct. The information contained in
this record has no relevance to the linking process, but is provided
by the language translator for debugging purposes.
BLKEND
+----------+
|7C|RLEN|CS|
+----------+
The Block End Record provides information about the scope of variables
and procedures in the source file. ELINK skips over this record, but
does verify that the checksum is correct. The information contained
in this record has no relevance to the linking process, but is
provided by the language translator for debugging purposes.
Page 4
COMENT
+-------------------------------+
|88|RLEN|COMMENT TYPE|COMMENT|CS|
+-------------------------------+
The Comment Record allows language translators to include commentary,
often proprietary, information in the object files. One particular
form of this record is the cornerstone to PharLap's 32-bit OMF
extension scheme. More on that later. ELINK reads and decodes this
record just enough to see if it's the PharLap 32-bit comment record.
Other than that, it is skipped and the checksum verified.
DEBSYM
+---------------------------------------------------+
|7E|RLEN|FRAME INFO|SYMBOL NAME|OFFSET|TYPE INDEX|CS|
+------------------+-----------------------------+--+
| Repeated |
+-----------------------------+
The Debug Symbols Record provides information about local symbols
including stack and based symbols. ELINK skips over this record, but
does verify that the checksum is correct. The information contained
in this record has no relevance to the linking process, but is
provided by the language translator for debugging purposes.
EXTDEF
+-----------------------------------+
|8C|RLEN|EXTERNAL NAME|TYPE INDEX|CS|
+-------+------------------------+--+
| Repeated |
+------------------------+
The External Names Definition Record is used to provide a list of
external names and what type of object each is. ELINK will match each
name in the list with an identical public name, if found. Unlike most
linkers, ELINK does not enforce the matching requirement if no
reference to a given external name is found in the object module. In
other words, if FOO is declared external, but is not used, most
linkers will insist that FOO be declared and defined somewhere. ELINK
doesn't. ELINK doesn't attempt to enforce the type checking referred
to in the type index, as every language translator I've encountered
leaves a zero in the type index field, which means "the untyped type".
If the language translator doesn't provide the information to perform
type checking, the linker can't do it.
Page 5
FIXUPP
+--------------------------+
|9C|RLEN|THREAD or FIXUP|CS|
+-------+---------------+--+
| Repeated |
+---------------+
The Fixup Record provides the information necessary to resolve
references. These records preserve the information about whether the
reference is a single-byte displacement, a pointer with segment and
offset, etc. The THREAD fields are formatted as follows:
+-----------------------------+
|TRD DAT|INDEX or FRAME NUMBER|
+-------+---------------------|
| Conditional |
+---------------------+
The TRD DAT field is a single byte formatted as follows:
+------------+
|0|D|0|MMM|TT|
+------------+
Where D is the thread type (0 = target, 1 = frame), MMM is the method
(T0 through T7 if a target thread, F0 through F6 if a frame thread),
and TT is the thread number, 0 to 3. The method identifies whether an
index or a frame number follows, or if it follows, and if an index,
what it is an index to. These methods are:
T0: The index is a segment index; a displacement will be used
T1: The index is a group index; a displacement will be used
T2: The index is an external index; a displacement will be used
T3: The following word is the frame; a displacement will be used
T4: The index is a segment index; no displacement
T5: The index is a group index; no displacement
T6: The index is an external index; no displacement
T7: The following word is the frame; no displacement
F0: The index is a segment index
F1: The index is a group index
F2: The index is an external index
F3: The following word is a frame
F4: No index or frame word
F5: No index or frame word
F6: No index or frame word
Frame methods F3 and F6 and target methods T3 and T7 are not used by
Microsoft or PharLap.
Page 6
A frame, by the way, is simply the segment part of the segment:offset
address. As you probably know, any 20-bit physical address can be
expressed by any of 4,096 different segment:offset pairs. The
canonical frame, as Intel calls it, is the segment of the
segment:offset pair with the smallest offset. The frame of a segment
or a group, as used in resolving the fixups, is the segment's or
group's canonical frame.
The FIXUP field is formatted as follows:
+----------------------------------------------------------+
|LOCAT|FIX DAT|FRAME DATUM|TARGET DATUM|TARGET DISPLACEMENT|
+-------------+-----------+------------+-------------------|
|Conditional|Conditional | Conditional |
+--------------------------------------------+
The LOCAT field is a pair of bytes formatted as follows:
+--------------------+
|1|M|0|LLL|OOOOOOOOOO|
+--------------------+
Where M is the fixup mode (0 = self-relative, 1 = segment-relative),
LLL is the type of fixup (000 = low byte, 001 = offset, 010 = base,
011 = pointer, 100 = high byte, 101 = loader-resolved offset, 110 and
111 are illegal. PharLap does not support type 101 as described
here), and OOOOOOOOOO is the offset in the previous LEDATA or LIDATA
record that the fixup applies to.
The FIX DAT field is a byte formatted as follows:
+------------+
|F|FRM|T|P|TG|
+------------+
Where F is the frame specifier (0 = explicit frame, 1 = frame provided
by a frame thread), FRM is the frame method (F0..F6 if an explicit
frame is referenced, frame thread number 0..3 if a frame thread is
referenced), T is the target specifier (0 = explicit target, 1 =
target provided by a target thread), P is the primary field (0 =
primary target, requires a displacement, or 1 = secondary, requires no
displacement), and TG is the target method (T0..T7 if an explicit
target is referenced (P is interpreted as the high-order bit), target
thread 0..3 if a thread target is referenced). Note that the frame
and target threads defined by the THREAD fields provide a shorthand
for the FIXUP fields that follow.
The FRAME DATUM field is a segment, group or external index or a
frame; if the FIX DAT field references a frame thread or explicitly
references frame methods F4, F5 or F6, this field is omitted.
Page 7
The TARGET DATUM field is a segment, group or external index or a
frame; if the FIX DAT field references a target thread, this field is
omitted.
The TARGET DISPLACEMENT field is the displacement referred to in the
target methods T0 to T3. It is present if the target thread or the
explicit target method specify a primary target reference (a reference
with displacement).
The frame method and target methods together are used to determine the
segment and offset of the unresolved reference. They are the heart
and soul of the linker.
GRPDEF
+------------------------------------------------------+
|9A|RLEN|GROUP NAME INDEX|GROUP COMPONENT DESCRIPTOR|CS|
+------------------------+--------------------------+--+
| Repeated |
+--------------------------+
The Group Definition Record provides information about groups used in
the module. The GROUP COMPONENT DESCRIPTOR fields may be in any of
the following five formats:
+----------------+
|FF|SEGMENT INDEX|
+----------------+
+-----------------+
|FE|EXTERNAL INDEX|
+-----------------+
+---------------------------------------------------------+
|FD|SEGMENT NAME INDEX|CLASS NAME INDEX|OVERLAY NAME INDEX|
+---------------------------------------------------------+
+--------------------------------------------+
|FB|LTL DAT|MAXIMUM GROUP LENGTH|GROUP LENGTH|
+--------------------------------------------+
+----------------------+
|FA|FRAME NUMBER|OFFSET|
+----------------------+
Of these five, only the first is used by Microsoft or PharLap, and
only the first format is supported by ELINK.
Page 8
LEDATA
+--------------------------------------------------------+
|A0|RLEN|SEGMENT INDEX|ENUMERATED DATA OFFSET| DATA |CS|
+--------------------------------------------+--------+--+
|Repeated|
+--------+
The Logical Enumerated Data Record, contains the bulk of the code and
data created by the language translator. The record is limited to
1024 bytes of enumerated bytes of data. Oddly enough, that happens to
be the limit of what the 10-bit offset field of a FIXUPP record's
LOCAT field can index.
LIDATA
+-------------------------------------------------------------+
|A2|RLEN|SEG INDEX|ITERATED DATA OFFSET|ITERATED DATA BLOCK|CS|
+--------------------------------------+-------------------+--+
| Repeated |
+-------------------+
The Logical Iterated Data Record contains the iterated code in a
shorthand form. The ITERATED DATA BLOCK fields are formatted as
follows:
+--------------------------------+
|REPEAT COUNT|BLOCK COUNT|CONTENT|
+--------------------------------+
The REPEAT COUNT field is the count of how many times the following
block(s) will be repeated. The BLOCK COUNT field is a count of the
ITERATED DATA BLOCK fields that will be in the CONTENT field. If the
BLOCK COUNT field is zero, the CONTENT field consists of a single byte
holding the count of data bytes, followed by the data bytes
themselves. Not coincidentally, the recursive nature of this record
mimics the recursive syntax of the assembly language DUP directive.
Page 9
LINNUM
+----------------------------------------------------------+
|94|RLEN|LINE NUMBER BASE|LINE NUMBER|LINE NUMBER OFFSET|CS|
+------------------------+------------------------------+--+
| Repeated |
+------------------------------+
The Line Numbers Record is used to provide a correspondence between
the individual lines of a source file and the translated code. The
data recorded includes the LINE NUMBER BASE field (which group or
segment the code is defined in), the LINE NUMBER fields, and the LINE
NUMBER OFFSET fields (the offsets of the code relative to the start of
the segment or group). ELINK stores this information in files to
which the -LINE switch applies and places it in the map file. The
LINE NUMBER BASE field is formatted exactly the same as the PUBLIC
BASE field in the PUBDEF record.
LNAMES
+-------------------+
|96|RLEN| NAME |CS|
+-------+--------+--+
|Repeated|
+--------+
The List of Names Record is used to provide a list of the names of
segments, groups, classes and overlays referenced in the module.
Page 10
MODEND
+---------------------------------+
|8A|RLEN|MOD TYPE|START ADDRESS|CS|
+----------------+-------------+--+
| Conditional |
+-------------+
The Module End Record identifies the end of the module; it should be
the last record in the file. It also is used to identify a start
address to the linker. ELINK ignores that aspect of the record. The
MOD TYPE field is a single byte formatted as follows:
+----------+
|MM|00000|L|
+----------+
Where MM is either 00 (non-main module, no start address), 01 (non-
main module with start address), 10 (main module, no start address) or
11 (main module with start address) and L is either 0 (the start
address is a physical address) or 1 (the start address is a logical
address requiring fixing up by the linker). The START ADDRESS field
is defined as follows:
+----------------------------------------------------+
|END DAT|FRAME DATUM|TARGET DATUM|TARGET DISPLACEMENT|
+-------+-----------+------------+-------------------|
|Conditional|Conditional | Conditional |
+--------------------------------------------+
for logical addresses, or
+-------------------+
|FRAME NUMBER|OFFSET|
+-------------------+
for physical addresses. For a discussion of the logical address, see
the description of the FIXUPP record.
Page 11
PUBDEF
+-----------------------------------------------------------+
|90|RLEN|PUBLIC BASE|PUBLIC NAME|PUBLIC OFFSET|TYPE INDEX|CS|
+-------------------+------------------------------------+--+
| Repeated |
+------------------------------------+
The Public Names Definition Record is used to provide a list of public
names. These are the global or public symbols declared in the source
files. The data recorded include the PUBLIC BASE field (which
describes which group or segment the name is defined in), the PUBLIC
NAME fields, the PUBLIC OFFSET fields (which provide the offsets of
the symbols relative to the start of the segment or group), and the
TYPE INDEX fields (which are supposed to be indices of TYPDEF
records). These fields, except the TYPE INDEX fields, are recorded by
ELINK for matching to external names. These names are the names that
will appear in the map file. The public base is formatted as follows:
+--------------------------------------+
|GROUP INDEX|SEGMENT INDEX|FRAME NUMBER|
+-------------------------+------------|
|Conditional |
+------------+
The FRAME NUMBER field is present only if both the group index and the
segment index are 0.
SEGDEF
+---------------------------------------------------------------+
|98|RLEN|SEG ATTR|SEG LEN|SEG INDEX|CLASS INDEX|OVERLAY INDEX|CS|
+------------------------+-----------------------------------+--+
| Conditional |
+-----------------------------------+
The Segment Definition Record describes a segment used in the module.
Fields in other records that are described as segment indices refer to
these records; segment index 1 refers to the first SEGDEF record,
index 2 to the second, and so forth. The mandatory fields are the
SEGMENT ATTRIBUTE and SEGMENT LENGTH fields; the optional fields are
indices to LNAMES records containing the segment's segment name (if
any), class name (if any) and overlay name (if any). The SEGMENT
ATTRIBUTE field is formatted as follows:
+------------------------------------------------------------+
|ACBP|FRAME NUMBER|OFFSET|LTL DAT|MAX SEG LENGTH|GROUP OFFSET|
+----+-------------------+-----------------------------------|
| Conditional | Conditional |
+-------------------------------------------------------+
Page 12
The ACBP field is a single byte formatted as follows:
+-----------+
|AAA|CCC|B|0|
+-----------+
Where AAA is the segment alignment (000 = absolute segment, 001 = byte
aligned segment, 010 = word aligned segment, 011 = paragraph aligned
segment, 100 = page aligned segment, 101 = unnamed absolute portion of
memory, 110 = load-time locatable (LTL) paragraph-aligned segment; 111
is undefined. Microsoft and PharLap do not use 101 or 110 except in
their 32-bit extensions), CCC is the combination attribute (000 =
private, 001 = undefined, 010 = public, 011 = undefined, 100 = public,
101 = stack, 110 = common, 111 = public), and B is the big segment
attribute (if 1, the segment length is exactly 65,536 bytes). The
FRAME NUMBER and OFFSET fields are present only if the segment
alignment field is 000. The LTL DAT, MAX SEG LENGTH and GROUP OFFSET
fields are only present if the segment alignment is 110, which is not
supported by Microsoft or PharLap.
THEADR
+----------------------+
|80|RLEN|MODULE NAME|CS|
+----------------------+
The T-Module Header Record provides the module name for the object
file. Object files should have only one module name. ELINK uses this
record to provide the module name in output files.
TYPDEF
+--------------------------------+
|8E|RLEN|NAME|LEAF DESCRIPTORS|CS|
+------------+----------------+--+
| Repeated |
+----------------+
The Type Definition Record is used to describe the types of objects
described in PUBDEF, EXTDEF, BLKDEF and DEBSYM records. While all the
language translators I've used don't bother to provide meaningful type
indices, some go to great lengths to provide TYPDEF record after
TYPDEF record. Because ELINK does no type checking, these records are
verified but ignored.
Page 13
Microsoft Enhancements to OMF
The following Microsoft enhancements to OMF are also supported:
COMDEF
+---------------------------------------------------------+
|B0|RLEN|COMM NAME|TYPE INDEX|DATA SEG TYPE|COMM LENGTH|CS|
+-------+----------------------------------------------+--+
| Repeated |
+----------------------------------------------+
The Communal Names Definition Record is used to list communal
variables. A communal variable is an uninitialized public variable
whose size and location is undefined at the time of translation. The
DATA SEG TYPE field is a single byte and is either 61, indicating the
communal variable is FAR (not in the default data segment), or 62,
indicating the communal variable is NEAR (in the default data
segment). Near communal variables are placed in a segment called
c_common in the group DGROUP; far communal variables are placed in a
segment called FAR_BSS with the combine attribute of private.
LCOMDEF
+---------------------------------------------------------+
|B8|RLEN|COMM NAME|TYPE INDEX|DATA SEG TYPE|COMM LENGTH|CS|
+-------+----------------------------------------------+--+
| Repeated |
+----------------------------------------------+
The Local Communal Names Definition Record is used to list communal
variables that have no visibility outside their module. It is treated
the same as a COMDEF record.
LEXTDEF
+-----------------------------------+
|B4|RLEN|EXTERNAL NAME|TYPE INDEX|CS|
+-------+------------------------+--+
| Repeated |
+------------------------+
The Local External Names Definition Record is used to provide a list
of external names that are not visible outside their module. It is
treated the same as an EXTDEF record.
Page 14
LPUBDEF
+-----------------------------------------------------------+
|B6|RLEN|PUBLIC BASE|PUBLIC NAME|PUBLIC OFFSET|TYPE INDEX|CS|
+-------------------+------------------------------------+--+
| Repeated |
+------------------------------------+
or
+-----------------------------------------------------------+
|B7|RLEN|PUBLIC BASE|PUBLIC NAME|PUBLIC OFFSET|TYPE INDEX|CS|
+-------------------+------------------------------------+--+
| Repeated |
+------------------------------------+
The Local Public Names Definition Records are used to provide lists of
public names that are not visible outside their modules. They are
treated the same as PUBDEF records.
32-bit Enhancements to OMF
When the Intel 80386 CPU arrived on the scene, a problem arose: there
was no way to express a 32-bit value in any of the OMF records. How
could one do that? Well, as is so often the case in the DOS world,
there arose not one, but two solutions! Rather than debate which is
better, ELINK can handle either set of extensions, and can handle a
mixture of the two.
PharLap 32-bit Enhancements
PharLap offers a simple method of extending OMF to handle 32-bit
records: it uses a special COMENT record to indicate that 32-bit
extensions are used in the current module:
+--------------------------------+
|88|08 00|80|AA|38 30 33 38 36|3D|
+--------------------------------+
The "80386" COMENT record, if present in a module, modifies the
following records:
FIXUPP
The TARGET DISPLACEMENT fields for primary targets are changed from 2
bytes to 4 bytes. The type of fixup field in the LOCAT field in the
FIXUP field has 2 new values: 101 (32-bit offset) and 110 (48-bit
pointer).
LEDATA
The ENUMERATED DATA OFFSET field is changed from 2 bytes to 4 bytes.
Page 15
LIDATA
The ITERATED DATA OFFSET field is changed from 2 bytes to 4 bytes.
LINNUM
The LINE NUMBER OFFSET fields are changed from 2 bytes to 4 bytes.
MODEND
The TARGET DISPLACEMENT field of the START ADDRESS field is changed
from 2 bytes to 4 bytes.
PUBDEF
The PUBLIC OFFSET fields are changed from 2 bytes to 4 bytes.
SEGDEF
The SEGMENT LENGTH field is changed from 2 bytes to 4 bytes; the
OFFSET field of the SEGMENT ATTRIBUTE field is changed from 2 bytes to
4 bytes. 2 new values are added for the segment alignment field of
the ACBP field of the SEGMENT ATTRIBUTE field: 101 (segment is double-
word aligned) and 110 (segment is 4K-page aligned). An optional
attribute byte may also be included following the OVERLAY INDEX field;
it's formatted as follows:
+----------+
|00000|U|AT|
+----------+
Where U is the segment use attribute (0 = USE16, 1 = USE32) and AT is
the segment access type (00 = RO [read-only], 01 = EO [execute-only],
10 = ER [execute/read], and 11 = RW [read/write]).
Page 16
Microsoft 32-bit Enhancements
Microsoft's approach to 32-bit extensions to OMF was to create new
record types. With the exception of the LPUBDEF record, which can
have a record type of B7, all the OMF records have even numbers for
record types. Microsoft created new records that are equivalent to
existing records, with 1 added to the existing record's record type.
The following new records were created:
FIXUPP
The record type is 9D; the TARGET DISPLACEMENT fields for primary
targets are changed from 2 bytes to 4 bytes; the LOCAT field of the
FIXUP field is redefined as follows:
+-------------------+
|1|M|LLLL|OOOOOOOOOO|
+-------------------+
The fields are unchanged except the LLLL field; this field supports
the older types, as well as the following new values: 1001 (32-bit
offset), 1011 (48-bit pointer), and 1101 (loader-resolved 32-bit
offset).
LEDATA
The record type is A1; the ENUMERATED DATA OFFSET field is changed
from 2 bytes to 4 bytes.
LIDATA
The record type is A3; the ITERATED DATA OFFSET field and REPEAT COUNT
fields are changed from 2 bytes to 4 bytes.
LINNUM
The record type is 95; the LINE NUMBER OFFSET fields are changed from
2 bytes to 4 bytes.
MODEND
The record type is 8B; the TARGET DISPLACEMENT field of the START
ADDRESS field is changed from 2 bytes to 4 bytes.
PUBDEF
The record type is 91; the PUBLIC OFFSET fields are changed from 2
bytes to 4 bytes.
Page 17
SEGDEF
The record type is 99; the ACBP field of the SEGMENT ATTRIBUTE is re-
defined as follows:
+-----------+
|AAA|CCC|B|X|
+-----------+
As before, AAA is the segment alignment; the old alignments are
honored, as is 101 (double-word alignment). CCC is the combination
attribute and is unchanged. B is the big segment attribute; if set,
it indicates a segment of 4,294,967,296 bytes (4Gb). X is a new
field; if 0, the segment has the USE16 attribute; if 1, it has the
USE32 attribute.
How ELINK works
Each object file and library file is read, in the order they're
encountered on the command line and in response files. As each module
is read, its COMDEF, COMENT, EXTDEF, FIXUPP, GRPDEF, LEDATA, LIDATA,
LINNUM, LNAMES, MODEND, PUBDEF, SEGDEF and THEADR records are
translated into internal memory structures. After the files have been
read in, the EXTDEF structures are matched against the PUBDEF
structures and "master" segments structures are created from the
individual modules' segment structures. The master segment structures
are created in the order in which the module segment structures were
created; thus, the order of linkage is the order in which the segments
were described in the modules. The module segment structures are then
tagged as to which master segment structure they belong to. The map
file, if requested, is emitted at this point. The files are then re-
read, in the same order as before, and the FIXUPP-directed actions are
applied to the associated LEDATA and LIDATA data, and the linked code
emitted. The result of this is that the resulting linked file may
skip back and forth between one segment and another exactly as the
input modules did.
The rules for combining segments are as follows:
∙ The segments must have the same segment name. This cannot be
overridden.
∙ If one segment is part of a group, and another segment is not
explicitly in any group, the segments may be combined. If they
are both in groups, the groups must have the same group name.
∙ The segments must have the same class name. If one segment does
not have an explicit class name, but qualifies in all other ways
for combinig with a segment that does have a class name, it may
be combined with that segment if the -RELAXED switch is used.
∙ The segments must have the same overlay names. This is the only
use ELINK makes of overlay information.
Page 18
∙ The segments must have compatible combine types: public segments
can only combine with other public segments, common segments can
only combine with other common segments, stack segments can only
combine with other stack segments. Private segments cannot
combine with any other segments. A segment's combine type can be
changed by using the -COMBINE switch.
Page 19
Input
ELINK takes as its input multiple object and library files. No
distinction need be made by the user, as the two types of files are
readily distinguished by ELINK. The object files must be in the Intel
object module format (OMF) as described above; extensions to the Intel
OMF made by Microsoft and PharLap to support 80386 and 80486 32-bit
code as described above are also recognized. The library files must
be Microsoft compatible. ELINK has been successfully used to link
object and library files created by Microsoft, Borland, PharLap and
Metaware language translators, and has done so in a single session,
linking files created by all four translators at once. The only
failure of note has been in handling Borland 80386 32-bit files
created by TASM. Borland has chosen to reside in the Microsoft camp
as far as 32-bit extensions are concerned, but they don't support the
entire spectrum of those extensions. Unfortunately, ELINK cannot
fully support TASM output because of this limitation.
Page 20
Output
ELINK can create up to five different files as its output: an error
file, a warning file, a map file, a display file, and the true output
file (a file consisting of the successfully linked input files).
Errors
The error file is normally written to "stderr", which is usually the
console, and which can be redirected with a number of available
utilities. Error output cannot be disabled altogether, but can be
redirected via the -ERR switch.
Appendix A is a list of the error messages output by ELINK, what they
mean, and what (if anything) you can do about them.
Warnings
The warning file, like the error file, is normally written to
"stderr". Unlike errors, warnings can be disabled altogether, via the
-NOWARNING switch. Warnings can be redirected via the -WARNING
switch.
Appendix B is a list of the warning messages output by ELINK, what
they mean, and what (if anything) you can do about them.
Map file
The map file is not normally created; it must be explicitly requested
by using the -MAP switch. The map file output may be modified by use
of the -LINE, -NOADDRESS, -NOALPHA, -NOFILES, -NOLINE, -NOPARMS and
-NOSEGMAP switches. The map file is broken down into five parts; each
part may be suppressed by use of the appropriate switch.
Parameter List
The parameter list is a list of the command line parameters read from
the command line and from response files, if any. Two exceptions are
the -LINE and -NOLINE parameters; these parameters show up in the file
list, and will not show up if the file list is excluded by means of
the -NOFILES switch. No distinction is made between the two sources.
The parameter list and the file list by themselves can be used to
create a response file, and for that reason are included in the map
file. The -NOPARMS switch will disable inclusion of the parameter
list.
Page 21
File List
The file list is a list of the input files read from the command line
and from response files, if any. The file list will also have the
switches -LINE and -NOLINE before each filename unless the -NOPARMS
switch is used. No distinction is made between the two sources. The
parameter list and the file list by themselves can be used to create a
response file, and for that reason are included in the map file. The
-NOFILES switch will disable inclusion of the file list.
Segment Map
The segment map is a list of the segments, their group names (if any),
their combine types, their start addresses and their lengths. The -
NOSEGMAP switch disables inclusion of the segment map.
Symbol Lists
The symbols are listed both alphabetically and by address. Each list
contains the symbol name, its address, its group offset, the segment
and group the symbol is in, and the module it was defined in. In
addition, the list sorted by address will contain the line number
information, if any. The alphabetical list can be excluded by use of
the -NOALPHA switch, and the list sorted by address can be excluded by
use of the -NOADDRESS switch. Unless both symbol lists are excluded,
a cross-reference will also be generated, giving the input file for
each module name.
In order to keep listings neat, overly long symbol names are truncated
to thirteen significant characters; truncated names may be identified
by the "+" following them.
Verbose mode
The display file is not normally created; it must be explicitly
requested by using the -VERBOSE switch. The verbose output is written
to "stdout", which is usually the console, and can be redirected via
the DOS command line output redirection operator, ">", or the DOS
command line pipe operator, "|". With a filename, verbose output is
written to the specified file. In verbose mode, ELINK will produce
the following messages, in this order:
Pass1: reading filename (for each input file)
Resolving external references
Combining segments
Creating map file
Beginning 2nd pass
Pass2: reading filename (for each input file)
Memory use: value bytes
Page 22
Output file
The true output file, the result of linking the specified input files,
is by default Intel 16-bit hex. It can also be Intel 32-bit hex,
Motorola S-records, or Intel OMF. These formats are specified by
using the -HEX32, -OMF or -SRECORD switches. The default filename for
the output file is the first input filename with an extension of
".HEX". If this is not desired, the -HEX, -HEX32, -OMF or -SRECORD
switches can be used to specify a different filename.
Intel Hex
Intel hex is an ASCII representation of the linked code. All Intel
hex records are of the same general form:
+-----------------------------------------------+
|:|LENGTH|LOAD ADDRESS|RECORD TYPE|DATA|CHECKSUM|
+-----------------------------------------------+
The LENGTH field is a single byte indicating the number of bytes in
the DATA field. The LOAD ADDRESS is a 16-bit value indicating the
load address offset for a data record; all other records fill this
field with 0. The RECORD TYPE is a single byte indicating the type of
record. The DATA field is 0 or more bytes of data. The CHECKSUM
field is a two's complement sum of the bytes from the LENGTH field to
the DATA field. Standard Intel hex record types are:
00: Data Record (code and data are here)
01: End of File Record
02: Extended Segment Address Record (the segment frame is here)
03: Start Segment Address Record (the start address frame is here)
Intel Hex32
Intel hex32 is an ASCII representation of 32-bit linked code. It is
made up of the following Intel hex record types:
00: Data Record (code and data are here)
01: End of File Record
04: Extended Linear Address Record (the most significant word of the
physical address is here)
05: Start Linear Address Record (the most significant word of the
start physical address is here)
Page 23
Motorola S-records
Motorola S-records are an ASCII representation of 32-bit flat
(unsegmented) linked code. It is formatted in the following fashion:
+---------------------- -------+
|S3|BB|AAAAAAAA|DD|DD|∙∙∙|DD|SS|
+---------------------- -------+
Where S3 is a signature indicating a 32-bit Motorola data record, BB
is the byte count in hexadecimal, AAAAAAAA is the 32-bit offset in
hexadecimal, DD are data bytes in hexadecimal, and SS is the checksum.
The byte count is the sum of the count of data bytes plus five (one
for the single-byte checksum and four for the four-byte address). The
byte count, the four bytes of the address, the data bytes and the
checksum sum to 0FFH.
OMF
The OMF format is supported for downloading code into in-circuit
emulators (ICE). It is for 16-bit code only. The file format is very
similar to an object file, except that there are no FIXUPP records.
Merging output files
The error file, warning file, map file and display files may be merged
with one another by using the same filename with more than one of the
-ERR, -MAP, -VERBOSE or -WARNING switches.
The output file cannot have the same filename as the error, map,
display or warning files.
Page 24
Return values
The following values are returned by ELINK and can be tested for in a
batch file:
+--------------------------------------------------------------+
|Hex|Decimal|Meaning |
|---+-------+--------------------------------------------------|
| 00| 0 |Normal return value |
|---+-------+--------------------------------------------------|
| 01| 1 |Warnings were generated |
|---+-------+--------------------------------------------------|
| 02| 2 |ELINK was invoked with no arguments |
|---+-------+--------------------------------------------------|
| 80| 128 |Invalid parameter on command line |
| | |--------------------------------------------------|
| | |No files specified on command line |
|---+-------+--------------------------------------------------|
| 81| 129 |Error occurred during pass 1 |
|---+-------+--------------------------------------------------|
| 82| 130 |Error occurred while verifying external references|
| | |--------------------------------------------------|
| | |Error occurred while combining segments |
| | |--------------------------------------------------|
| | |Error occurred while creating map file |
|---+-------+--------------------------------------------------|
| 83| 131 |Conflicting output file requirements |
| | |--------------------------------------------------|
| | |Error opening output file |
| | |--------------------------------------------------|
| | |Error closing output file |
|---+-------+--------------------------------------------------|
| 84| 132 |Error occurred during pass 2 |
+--------------------------------------------------------------+
Page 25
The ELINK command line
ELINK allows the user to specify what files are to be linked and to
modify its behavior by specifying the input filenames and switches on
the DOS command line, inside response files, or both.
A response file is an ASCII text file that may contain the names of
files to be linked and switches to modify ELINK's behavior. This is a
convenient way to specify a set of switches you commonly use, or a set
of files you want to link together, or both. More than one response
file may be used.
Unlike many programs that use the command line or response files,
ELINK is largely unconcerned with the order of placement of filenames
and switches in the command line or response files. There are
exceptions to this:
∙ Files are linked in the order they appear in the command line and
response files.
∙ The -COMMENT switch affects subsequent response files. If used
within a response file, it affects subsequent lines within the
current response file as well.
∙ The -LINE and -NOLINE switches affect the processing of line
number information in subsequent filenames. If used within a
response file, it affects subsequent filenames within the current
response file as well.
∙ When mutually contradictory switches are found in the ELINK
command line, such as -DUPERR and -DUPOK, the conflict is
silently resolved in favor of the last switch encountered.
How ELINK reads its command line
ELINK treats any command line parameter beginning with "-" as a
switch, any command line parameter beginning with "@" as the name of a
response file, and any other parameters as filenames.
A response file is a list of filenames and switches. Switches and
filenames are distinguished as on the command line. Response files
are not allowed within response files, however. Each line of the
response file may contain one switch or one filename. The filename or
switch does not have to start in any particular column. Comments are
allowed inside response files. By default, comments begin with a ";".
You can use the -COMMENT switch to change this.
All parameters are case-insensitive; -Case, -CASE, -case, etc, are all
equivalent. The only exception to this is in switches used to modify
ELINK's behavior with respect to switches containing the names of
segments, classes, etc. If case-sensitivity is specified, then those
names must be in the proper case.
Page 26
The ELINK command line: an example
Let's use the following ELINK command line as an example:
ELINK aa.bbb @cc.ddd -case ee.fff -noline @gg.hhh ii.jjj
aa.bbb is the name of a file to be linked.
cc.ddd is the name of a response file; it contains the following
lines:
;
; this is a comment
;
kk.lll ; deframmisizer
mm.nnn ; antikludge code
-relaxed
;
oo.ppp
-comment=#
kk.lll is the name of a file to be linked, as is mm.mmm.
-relaxed is a switch.
oo.ppp is the name of another file to be linked.
-comment=# is a switch changing the response file comment character to
"#"
Back to the command line now...
-case is another switch
ee.fff is the name of a file to be linked.
-noline is a switch; further files will not have line number
information processed
gg.hhh is another response file; it contains the following lines:
qq.rrr #data
ss.ttt #code
#uu.vvv
-line
qq.rrr is the name of another file to be linked; so is ss.ttt.
-line is a switch; further files will have line number information
processed.
Note the use of "#" as a comment delimiter.
Finally, ii.jjj is the name of another file to be linked.
Page 27
So what does this mean? ELINK will link the files aa.bbb, cc.ddd,
kk.lll, mm.nnn, oo.ppp, qq.rrr, ss.ttt and ii.jjj, in that order.
Line number information will be processed for all the files except
qq.rrr and ss.ttt, as dictated by the use of the -noline and -line
switches (line number information is processed by default). Matching
of all symbols in all files will be case-sensitive, as dictated by the
-case switch, and all segments not formally placed in a group will be
combined with equivalent segments that are formally placed in a group,
as dictated by the -relaxed switch.
Switches
-CASE
By default, matching of names is case-insensitive. Using this switch
makes name matching case-sensitive.
-COMBINE=name:[PRIVATE,PUBLIC,STACK,COMMON]
In order for two segments to be combined by ELINK, the segments must
have compatible combine types. This switch allows the user to
override the language translator's choice for the specified segment.
This can be used to force segments together, or to force segments
apart.
-COMMENT
By default, response files use semicolons to delimit comments -
everything on a line to the right of the comment character is ignored
by ELINK. This switch allows the user to choose a different
character.
-DUPERR
By default, multiply defined public names are viewed as an alarming
anomaly and ELINK generates a warning for each duplicate. This switch
elevates the handling of this event to an error.
-DUPOK
By default, multiply defined public names are viewed as an alarming
anomaly and ELINK generates a warning for each duplicate. This switch
causes ELINK to ignore this event.
-ERR=filename
By default, errors are written to "stderr", which is usually the
console, and which can be redirected with a number of available
utilities. This switch eliminates the need to use such utilities by
allowing the user to specify the name of a file to which errors can be
written.
Page 28
-FLAT
By default, the data in each distinct segment and group begins at
offset 0; in flat mode, where the concept of separate segments and
groups exists primarily as a means to keep similar objects
(uninitialized data, constant data, code, etc.) together, offsets
continue to grow with each segment or group. This is of use in non-
segmented architectures, such as the Intel 80386 or 80486 or the
Motorola CPUs. The -SRECORD switch, used to create Motorola S-
records, implies this switch.
-HEX[=filename]
By default, ELINK's output is Intel 16-bit hex. By itself, then, this
switch does nothing except affirm this. With the optional filename,
the output filename is changed to the filename specified.
-HEX32[=filename]
By default, ELINK's output is Intel 16-bit hex. By itself, this
switch changes the output format to Intel 32-bit hex. With the
optional filename, the output filename is changed to the filename
specified. It is an error to use this switch with -NO32.
-LINE
By default, line number information is processed for inclusion in the
map file. This can be disabled by the -NOLINE switch and enabled by
this switch on a file-by-file basis.
-MAP=filename
By default, ELINK does not create a map file; this switch causes one
to be generated with the filename specified.
-NO32
By default, ELINK allows 32-bit code to be linked; this switch causes
a fatal error if 32-bit records are encountered. It is an error to
use this switch with either -HEX32 or -SRECORD.
-NOADDRESS
By default, the map file contains a list of public symbols sorted by
address. This switch disables inclusion of this list.
-NOALPHA
By default, the map file contains a list of public symbols sorted
alphabetically. This switch disables inclusion of this list.
Page 29
-NOFILES
By default, the map file contains a list of files linked. This switch
disables inclusion of this list.
-NOLINE
By default, line number information is processed for inclusion in the
map file. This can be enabled by the -LINE switch and disabled by
this switch on a file-by-file basis.
-NOPARMS
By default, the map file contains a list of parameters used. This
switch disables inclusion of this list.
-NOSEGMAP
By default, the map file contains a list of segments linked. This
switch disables inclusion of this list.
-NOWARNING
By default, warnings are enabled. This switch disables warning
generation.
-OFFSET=[CLASS,SEGMENT,OVERLAY]:name:offset
By default, the data in each distinct segment and group begins at
offset 0; in flat mode, where the concept of separate segments and
groups exists primarily as a means to keep similar objects
(uninitialized data, constant data, code, etc.) together, offsets
continue to grow with each segment or group. This is of use in non-
segmented architectures, such as the Intel 80386 or 80486 or the
Motorola CPUs. This switch allows the specified segment to begin at
the specified offset.
-OMF[=filename]
By default, ELINK's output is Intel 16-bit hex. By itself, this
switch changes the output format to Intel OMF. With the optional
filename, the output filename is changed to the filename specified.
-RELAXED
In order for two segments to be combined by ELINK, the segments must
have the same class name. This switch allows ELINK to combine two
segments that are otherwise combinable, but one has a class name
defined, and the other does not.
Page 30
-SRECORD[=filename]
By default, ELINK's output is Intel 16-bit hex. By itself, this
switch changes the output format to Motorola S-records. With the
optional filename, the output filename is changed to the filename
specified. As this format does not support a segmented architecture,
use of this switch implies -FLAT. It is an error to use this switch
with -NO32.
-VERBOSE[=filename]
By default, verbose output is suppressed. This switch, without a
filename, causes verbose output to be written to "stdout", which is
usually the console, and can be redirected via the DOS command line
output redirection operator, ">", or the DOS command line pipe
operator, "|". With a filename, verbose output is written to the
specified file.
-WARNING=filename
By default, warnings are written to "stderr", which is usually the
console, and which can be redirected with a number of available
utilities. This switch eliminates the need to use such utilities by
allowing the user to specify the name of a file to which warnings can
be written.
Page 31
Appendix A: Error Messages
32-bit code detected, not allowed
A 32-bit record was found in the first pass reading one of the
object files. You specified -NO32. Either don't use the -NO32
switch, or check the object file: you have 32-bit code where you
weren't expecting it.
A1: Illegal index: count
An attempt was made to add a segment's map to the combined
segment map; the pointer to the current object file's data
structure could not be found. Memory has apparently been
corrupted. Verify that no TSR's are conflicting with ELINK and
that no hardware memory errors could be causing the problem.
Then contact the author.
A2: Illegal index: count
An attempt was made to add a segment's map to the combined
segment map; the segment index was out of range. The object file
may be corrupted or incompatible with ELINK or an error was made
reading the file. Check the file and verify that the file is
completely readable.
Aborted
There were unresolved references, a failure to combine the
defined segments, or there were problems writing the map file
out. Previous error messages should indicate exactly what
happened.
Can't delete old backup file filename
The backup file created by ELINK previously cannot be deleted.
The file is probably read-only. Either rename the file or remove
the read-only attribute.
Can't open filename for read
The specified file could not be read. The file does not
apparently exist. Check for a typo in the command line or
response file.
Can't open filename for write
The specified file could not be created. Your disk is full or
your system is corrupted. Check your disk.
Page 32
Can't rename filename to filename
ELINK has attempted to back up the old output file. It could not
be renamed. Your system appears to be malfunctioning.
Can't use 2 error file
You attempted to use -ERR twice to specify an error file. Don't
do that.
Can't use 2 map files
You attempted to use -MAP twice to specify a map file. Don't do
that.
Can't use 2 output files
You attempted to use -HEX, -HEX32, -OMF or -SRECORD twice or in
combination to specify an output file. Don't do that.
Can't use 2 warning files
You attempted to use -WARNING twice to specify a warning file.
Don't do that.
Conflicting output requirements
You used the -NO32 switch with either the -HEX32 or -SRECORD
switches. You can't do that.
Error reading file
A file read failed. The file is corrupted or the disk system
failed.
Error writing output file
An error occurred while writing to a file. The disk is full or
the disk system is malfunctioning.
F1: Illegal index: count
An attempt was made to look up a name in the current object
file's data structure; the pointer to the current object file's
data structure could not be found. Memory has apparently been
corrupted. Verify that no TSR's are conflicting with ELINK and
that no hardware memory errors could be causing the problem.
Then contact the author.
Page 33
F2: Illegal index: count
An attempt was made to look up a name in the current object
file's data structure; the name index was out of range. The
object file may be corrupted or incompatible with ELINK or an
error was made reading the file. Check the file and verify that
the file is completely readable.
Illegal combine override type: type
An override of a segment's combine type was made with a combine
type of other that COMMON, PRIVATE, PUBLIC or STACK. Check your
command line or response file for typo's.
Illegal count
A byte count in a 16-bit segment exceeded 65,535. One or more
object files may be defective or incompatible with ELINK, or the
language translator attempted to place more data in a segment
than would fit.
Illegal offset
A segment offset in excess of 65,535 was found in a 16-bit
segment. One or more object files may be defective or
incompatible with ELINK, or the language translator attempted to
place more data in a segment than would fit.
Illegal offset override type: type
An offset override was attempted on an object other than a class,
overlay or segment. Check the command line or response files for
a typo.
Illegal segmentation
A non-zero segment frame was encountered in flat code. Your code
is segmented, but you specified -FLAT or -SRECORD (which implies
-FLAT). Check your source code.
Invalid group component descriptor value
The Intel OMF standard lists 5 group component descriptors; only
one, the segment index, is commonly supported by language
translators. This object file is not compatible with ELINK.
LEDATA record size out of range
The Intel OMF standard states that a Logical Enumerated DATA
(LEDATA) record cannot have a size field in excess of 1024 bytes.
Either the object file is defective or is incompatible with
ELINK.
Page 34
Memory allocation failed
ELINK attempted to allocate memory unsuccessfully. Try removing
TSR's, make sure you're nut running out of a shell, etc.
No files specified
You didn't specify any files to link...
Object file filename, module name: Cannot find reference to name
The specified module has an external reference that cannot be
resolved. Check your source files for typo's.
Overrun
The data being written wrapped at the top of the segment. Check
your code; you have too much data in one of your segments, or you
have too many ORG directives.
Pass1: abnormal termination of filename read
The file being read was stopped during the first pass. A
previous error message should be more specific.
Pass1: bad checksum: value, record type value
The file being read contained a bad checksum in one of its
records. The object file is corrupt or incompatible with ELINK.
Pass1: error reading file filename
A file read failed. The file is corrupted or the disk system
failed.
Pass1: error reading library file filename
A file read failed. The file is corrupted or the disk system
failed.
Pass1: error seeking in library file filename
During an attempt to read the next module in the specified
library file, the seek to the start of the next module failed.
The library file is corrupt, incompatible with ELINK, or the disk
system is malfunctioning.
Pass1: seek past library file filename index block
During an attempt to read the next module in the specified
library file, the address of the next module was calculated to be
past the library file's index block. The library file is
corrupt, incompatible with ELINK, or the disk system is
malfunctioning.
Page 35
Pass2: abnormal termination of filename read
The file being read was stopped during the second pass. A
previous error message should be more specific.
Pass2: bad checksum: value
The file being read contained a bad checksum in one of its
records. The object file is corrupt or incompatible with ELINK.
This is more serious than the pass 1 message, as the file read
without error on the first pass.
Pass2: error reading file filename
A file read failed. The file is corrupted or the disk system
failed. This is more serious than the pass 1 message, as the
file read without error on the first pass.
Pass2: error reading library file filename
A file read failed. The file is corrupted or the disk system
failed. This is more serious than the pass 1 message, as the
file read without error on the first pass.
Pass2: error seeking in library file filename
During an attempt to read the next module in the specified
library file, the seek to the start of the next module failed.
The library file is corrupt, incompatible with ELINK, or the disk
system is malfunctioning. This is more serious than the pass 1
message, as the file read without error on the first pass.
Pass2: seek past library file filename index block
During an attempt to read the next module in the specified
library file, the address of the next module was calculated to be
past the library file's index block. The library file is
corrupt, incompatible with ELINK, or the disk system is
malfunctioning. This is more serious than the pass 1 message, as
the file read without error on the first pass.
S1: Illegal index: count
An attempt was made to log a reference to an external symbol in
the current object file's data structure; the pointer to the
current object file's data structure could not be found. Memory
has apparently been corrupted. Verify that no TSR's are
conflicting with ELINK and that no hardware memory errors could
be causing the problem. Then contact the author.
Page 36
S2: Illegal index: count
An attempt was made to log a reference to an external symbol in
the current object file's data structure; the name index was out
of range. The object file may be corrupted or incompatible with
ELINK or an error was made reading the file. Check the file and
verify that the file is completely readable.
Symbol name in module name also defined in module name
The symbol was declared public in two different modules; the
-DUPERR switch was specified on the command line or in a response
file, making this an error. Fix the files or don't use the
-DUPERR switch.
Unrecognized parameter -switch
The specified switch is not recognized. Check the command line
or response files for a typo.
Page 37
Appendix B: Warnings
Frame error
This is a result of a self-relative fixup attempted on an object
that is one frame relative to an object in another frame. This
is usually a result of the language translator acting under the
assumption that the objects were in the same frame. Check that
the objects are in the matching segments and re-translate or use
the -RELAXED or -COMBINE switches.
GET_FIXDAT FAILURE
The object file being linked is not compatible with ELINK or is
corrupted.
Object file filename has more than one module name
Object files are only supposed to contain one module name. The
object file may not be compatible with ELINK.
Segment CLASS:name OVERLAY:name SEGMENT:name in more than one group
More than one group contains the specified segment. Check the
source and remove the inappropriate grouping.
Symbol name in module name also defined in module name
The symbol was declared public in two different modules. Fix the
files or use the -DUPOK switch.
Symbol name in module name, file filename declared external but not
used
The specified symbol is declared external in the specified
module, but there is no reference to it. This is usually due to
modified source files that used to refer to the symbol, but no
longer do, and still have the reference declared external. Some
language translators use the trick of generating external
definition records that aren't referenced for the purpose of
forcing the linker to include startup code, library objects, etc.
ELINK is not bound to include such code.
Unknown module type value, offset value
A module record of the specified type, at the specified value, is
not recognized by ELINK. This object file may not be compatible
with ELINK.
Page 38
Index
-CASE 27, 28
example 27
usage 28
-COMBINE 19, 28, 34, 38
syntax 28
usage 28
-COMMENT 26, 27, 28
example 27
order of placement 26
usage 28
-DUPERR 26, 28, 37
usage 28
-DUPOK 26, 28, 38
usage 28
-ERR 21, 24, 28, 33
syntax 28
usage 28
-FLAT 29, 31, 34
usage 29
-HEX 23, 29, 33
syntax 29
usage 29
-HEX32 23, 29, 33
inconsistent with other switches 29, 33
syntax 29
usage 29
-LINE 10, 21, 22, 26, 27, 29, 30
example 27
order of placement 26
usage 29
-MAP 24, 29, 33
syntax 29
usage 29
-NO32 29, 31, 32, 33
inconsistent with other switches 29, 33
usage 29
-NOADDRESS 21, 22, 29
usage 29
-NOALPHA 21, 22, 29
usage 29
-NOFILES 21, 22, 30
usage 30
-NOLINE 21, 22, 26, 27, 29, 30
example 27
order of placement 26
usage 30
-NOPARMS 21, 22, 30
usage 30
-NOSEGMAP 21, 22, 30
usage 30
Page 39
-NOWARNING 21, 30
usage 30
-OFFSET 30, 34
syntax 30
usage 30
-OMF 23, 30, 33
syntax 30
usage 30
-RELAXED 18, 27, 30, 38
example 27
usage 30
-SRECORD 23, 29, 31, 33, 34
and -FLAT 29, 31, 34
inconsistent with other switches 31, 33
syntax 31
usage 31
-VERBOSE 22, 24, 31
syntax 31
usage 31
-WARNING 21, 24, 31, 33
syntax 31
usage 31
32-bit code 3, 29
-NO32 29
default 29
80386 3, 29, 30, 31
flat memory model 29, 30, 31
80486 3, 29, 30
Command line 25, 26-28
example 27-28
parameters 26
case sensitivity 26
order of placement 26
-COMMENT 26
-LINE 26
-NOLINE 26
Errors 21, 25, 28, 29, 32-37
32-bit code 29, 32
abort 32
combine type 34
conflicting switches 33
default output device 21, 28
duplicated switches 33
-ERR 33
-HEX,-HEX32,OMF,-SRECORD 33
-MAP 33
-WARNING 33
group component descriptor 34
i/o 32, 33, 35, 36
illegal index 32, 33, 34, 36, 37
library files 35, 36
memory allocation 35
multiply defined public names 28, 37
offset override 34
Page 40
Errors (continued)
overrun 35
pass1 35
abnormal termination 35
bad checksum 35
pass2 36
abnormal termination 36
bad checksum 36
redirection 21, 28
return values 25
segmentation 34
unrecognized parameters 37
unresolved references 32, 35
values out of range 34
Fixups 6-8, 9, 15, 17, 38
load-time 3
methods 6, 7, 8
frame 6, 7, 8
target 6, 7, 8
modes 7
segment-relative 7
self-relative 7
threads 6, 7
types 7, 15, 17
Frames 7
Input 20
library files 20
object files 20
Input filenames 26
Line numbers 28, 29, 30
-LINE and -NOLINE 29, 30
default processing 28, 29, 30
Map file 21-22, 29, 30
creation 21, 29
default 21, 29
file list 22, 30
-LINE and -NOLINE 22
parameter list 21, 30
-LINE and -NOLINE 21
segment map 22, 30
symbol lists 22, 29, 30
alphabetical 22, 29
by address 22, 29
line numbers 22, 29, 30
module cross-reference 22
name truncation 22
Motorola processors 29, 30, 31
Names 5, 10, 12, 13, 28, 37, 38
class 10
external 5
group 10
matching 28
case sensitivity 28
-CASE 28
Page 41
Names (continued)
default 28
module 13, 38
publics 12, 28, 37, 38
multiply defined 28, 37, 38
default behavior 28
segment 10
OMF 3-18, 20, 34
BLKDEF 4, 13
BLKEND 4
COMENT 5, 15, 18
communal variables 14
conventions 4
DEBSYM 5, 13
enhancements 3, 5, 14-18, 20
16-bit 14-15, 18
COMDEF 14, 18
LCOMDEF 14
LEXTDEF 14
LPUBDEF 15
32-bit 3, 5, 15-18, 20
Borland 20
Microsoft 3, 17-18, 20
PharLap 3, 5, 15-16, 20
EXTDEF 5, 13, 14, 18
FIXUPP 6-8, 11, 15, 17, 18
GRPDEF 8, 18, 34
group component descriptors 8, 34
LEDATA 7, 9, 15, 17, 18, 34
LIDATA 7, 9, 16, 17, 18
LINNUM 10, 16, 17, 18
LNAMES 10, 12, 18
MODEND 11, 16, 17, 18
PUBDEF 10, 12, 13, 15, 16, 17, 18
SEGDEF 12, 13, 16, 18
THEADR 13, 18
TYPDEF 13
Output 21, 23-24, 29, 30, 31
filename 23, 24, 29, 30, 31
-HEX 23, 29
-HEX32 23, 29
-OMF 23, 30
-SRECORD 23, 31
merging files 24
format 23, 24, 29, 30, 31
default 23, 29, 30, 31
Intel 16-bit hex 23, 29
Intel 32-bit hex 23, 29
Intel OMF 23, 24, 30
Motorola S-records 23, 24, 31
Overlays 18
Response files 26, 27, 28
comments 26, 28
-COMMENT 28
Page 42
Response files (continued)
default character 26, 28
defined 26
example 27
how recognized 26
recursion 26
Return values 25
Segments 13, 16, 18-19, 28, 29, 30, 34, 38
access type 16, 18
alignment 13, 16, 18
big segment attribute 13, 18
combine types 13, 19, 28
-COMBINE 28
default 28
combining rules 18-19, 30, 34
class names 18, 30
-RELAXED 18, 30
default 18, 30
combine type 19, 34
group names 18
overlay names 18
segment names 18
groups 38
order of linkage 18
starting offsets 29, 30
-FLAT 29
-OFFSET 30
default behavior 29, 30
USE16 16, 18
USE32 16, 18
Switches 26, 28-31, 37
how recognized 26
invalid switches 37
resolution of contradictory switches 26
Verbose mode 21, 22, 31
-VERBOSE 22, 31
default 22, 31
Warnings 21, 25, 28, 30, 31, 38
default output device 21, 31
disabling 21, 30
frame errors 38
get_fixdat failure 38
multiple module names 38
multiply defined public names 28, 38
redirection 21, 31
return value 25
segment in multiple groups 38
unrecognized module type 38
unused externals 38
Page 43
